Most traditional file systems allocate disk space in units of storage space called allocation blocks or blocks. Uniform sized blocks are commonly supported across an entire file system. For instance, if a file system is created with blocks of 128K (bytes) in size, a new file created with a single byte written to it will consume 128K of storage space, because the file system will allocate 128K at a time, even if less is needed. When receiving a request to write 4K of data to a file, the file system may have to, in turn, first read a 128K size allocation block from a disk into memory, overwrite the 128K size block in memory with the 4K size data, and then write the entire 128K size block back to the disk. This causes performance overhead due to reading and writing the extra 124K of the block when that data are not needed or may not be initialized. This performance overhead has the cost of pushing other blocks out of virtual memory which may cause additional I/O activities.
On the other hand, using a small allocation block size, such as 4K, may require too much extra resources to be feasible for certain applications. For example, the smaller the block size, the larger the overhead of internal metadata structures in a file system, such as an associated checksum and pointers for each allocation block. As such, the amount of metadata that has to be read and paged into memory may increase 32 times when the allocation block size is reduced from 128K to 4K. In addition, media files such as movies and pictures tend to benefit from a lower overhead of using larger block sizes, when their data is intended to be read contiguously, rather than in a piecemeal fashion.
Furthermore, a uniform allocation block size for a file system may have a negative performance impact because different applications may access files in chunks of data in different sizes. For example, a database application, such as SQLite, may access record data from database files in units of 2K-4K sizes, known as the record size. Traditionally, a special file system may be required for the database application to allow manual configuration of an allocation block size matching the record size. However, as more and more different applications, e.g. mail, address book, photographs, and database, etc. are integrated under a high level framework, such as CoreData from Apple Inc., a specifically provisioned file system for one single application may not satisfy requirements of other applications.
Even if certain file systems, such as ZFS (Zettabyte File System), may support different sized allocation blocks within a single file system, these designs tend to be aggressively biased towards using a fixed target block size (e.g. 128K) as soon as the file is of a size no less than the fixed target block size (e.g. 128K).
Thus, traditional file systems do not adapt their access to associated storage media to account for the way certain applications use files without a manual intervention from the user. Generally, a user must identify performance bottlenecks before creating the file system in order to configure it appropriately.